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Today’s  Presenter 


Timothy  A.  Chick  is  a  senior  member  of  the  technical  staff  at  the  Software 
Engineering  Institute  (SEI)  where  he  works  on  the  Team  Software  Process  (TSP) 
Initiative. 


In  this  role,  Chick  is  responsible  for  defining,  developing,  and  transitioning  into 
practice  high-performance  software  and  systems  engineering  practices  based  on 
the  principles  and  concepts  in  TSP  and  Capability  Maturity  Model  Integration 
(CMMI).  His  work  includes  applied  research,  product  and  training  development, 
education/training  delivery,  and  consulting  in  the  domains  of  software 
engineering  and  systems  engineering  process  improvement. 

Chick  is  currently  an  SEI-Certified  CMMI  Instructor  and  TSP  Mentor  Coach,  and 
he  also  holds  a  Lean  Six  Sigma  Black  Belt  certification.  He  has  published 
numerous  technical  reports  and  bylined  technical  articles  in  top  industry 
publications  on  TSP  and  CMMI. 

Prior  to  joining  the  SEI,  he  worked  as  a  project  manager  for  Naval  Air  Systems 
Command  (NAVAIR),  leading  software  development  projects  and  software 
process  improvement  efforts  for  the  E-2C  Hawkeye  Program.  Chick  has  a 
bachelor  of  science  degree  in  computer  engineering  from  Clemson  University 
and  a  master  of  science  degree  in  computer  science  from  Johns  Hopkins 
University. 
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Topics 


Agile  Overview 

Selecting  the  Appropriate  Agile  Methods 
Maintaining  Consistency  and  Agility  using  TSP 
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Agile  or  agile 


Agile  O 

■ar-gpetip  of  software  development  methodologies  based 
on  iterative  and  incremental  development,  where 
requirements  and  solutions  evolve  through  collaboration 
between  self-organizing,  cross-functional  teams. 


agile  - 

’acterized  by  quickness,  lightness,  and  ease  of 
movement;  nimble. 

2.  Mentally  quick  or  alert. 
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Agile  Manifesto 

Manifesto  for  Agile  Software  Development 

February  2001 

We  are  uncovering  better  ways  of  developing 
software  by  doing  it  and  helping  others  do  it. 
Through  this  work  we  have  come  to  value: 


before 

Individuals  and  interactions  cvci  processes  and  tools 

before 

Working  software  o^^er  comprehensive  documentation 


before 

Customer  collaboration  cvci  contract  negotiation 


while 

Responding  to  change  over  following  a  plan 
That  is,  while  there  is  value  in  the  items  on  the  right, 
we  value  the  items  on  the  left  more. 


The  Twelve  Agile  Principles 

1 .  Our  highest  priority  is  to  satisfy  the  customer  through  early  and  continuous  delivery  of 
valuable  software. 

2.  Welcome  changing  requirements,  even  late  in  development.  Agile  processes  harness  change 
for  the  customer's  competitive  advantage. 

3.  Deliver  working  software  frequently,  from  a  couple  of  weeks  to  a  couple  of  months,  with  a 
preference  to  the  shorter  timescale. 

4.  Business  people  and  developers  must  work  together  daily  throughout  the  project. 

5.  Build  projects  around  motivated  individuals.  Give  them  the  environment  and  support  they  need, 
and  trust  them  to  get  the  job  done. 

6.  The  most  efficient  and  effective  method  of  conveying  information  to  and  within  a  development 
team  is  face-to-face  conversation. 

7.  Working  software  is  the  primary  measure  of  progress. 

8.  Agile  processes  promote  sustainable  development.  The  sponsors,  developers,  and  users 
should  be  able  to  maintain  a  constant  pace  indefinitely. 

9.  Continuous  attention  to  technical  excellence  and  good  design  enhances  agility. 

10.  Simplicity-the  art  of  maximizing  the  amount  of  work  not  done-is  essential. 

1 1 .  The  best  architectures,  requirements,  and  designs  emerge  from  self-organizing  teams. 

12.  At  regular  intervals,  the  team  reflects  on  how  to  become  more  effective,  then  tunes  and  adjusts 
its  behavior  accordingly. 
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Agile  Methods 


There  is  no  single  Agile  method,  but  there  are  several  methods  that 
are  shaped  by  Agile  principles. 

•  Extreme  Programming  (XP) 

•  SCRUM 

•  Dynamic  Systems  Development  Method  (DSDM) 

•  Adaptive  Software  Development 

•  Crystal 

•  Feature-Driven  Development 

•  Pragmatic  Programming 

•  TSP 

Today,  any  method  that  is  an  alternative  to  documentation  driven, 
heavyweight  software  development  processes  is  probably  an 
Agile  method. 
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Extreme  Programming  -1 

The  Twelve  Practices  of  XP 

1.  The  Planning  Game  -  XP  follows  an  iterative  development  process  and  the  planning 
game  is  used  to  develop  an  overall  plan,  the  release  plan,  and  the  iteration  plan. 

2.  On-site  customer  -  A  requirement  of  XP  is  to  include  a  customer  on  the  team  and  the 
customer  must  be  available  full-time  to  answer  questions  as  they  arise,  preferably  face  to 
face,  and  preferably  on  site. 

3.  Small  releases  -  The  product  is  built  in  small  releases  with  very  few  features 
implemented  during  each  iteration  (time  boxed). 

4.  Metaphor  -  XP  discourages  defining  an  architecture  or  creating  a  framework  for  the 
product  being  developed,  instead,  XP  uses  something  called  a  metaphor. 

The  metaphor  provides  an  idea  or  a  model  for  the  system,  which  developers  can 
use  as  guidance  during  the  entire  project. 

5.  Simple  design  -  The  design  is  kept  as  simple  as  possible.  You  only  do  enough  design 
to  implement  the  next  feature. 

6.  Testing  -  Programmers  write  automated  unit  tests  for  every  feature.  No  new  feature  is 
implemented  without  writing  the  unit  test  first.  The  customer  writes  acceptance  tests. 
Acceptance  tests  are  used  to  test  the  functionality  of  individual  features  of  a  product. 


Software  Engineering  Institute 


Carnegie  Mellon 


Timothy  A.  Chick,  July  201 1 

©2011  Carnegie  Mellon  University 
Twitter  #seiwebinar 


11 


Extreme  Programming  -2 

The  Twelve  Practices  of  XP  (continued) 

7.  Refactoring  -  Refactoring  improves  the  design  of  existing  code  by  making  it  simpler, 
faster,  more  robust,  cleaner,  or  by  eliminating  duplication,  without  changing  the 
function  of  the  code. 

8.  Pair  programming  -  All  production  code  is  written  with  two  people  using  one  machine, 
one  keyboard,  and  one  mouse.  Pairs  change  constantly.  Pair  programming  also 
includes  pair  designing  and  pair  unit  testing. 

9.  Collective  ownership  -  Any  developer  can  change  any  code  at  any  time. 

There  is  no  concept  of  code  ownership.  There  is  no  concept  of  a  system  architect  or 
a  keeper  of  the  vision. 

10.  Continuous  integration  -  The  system  is  integrated,  built,  and  unit-tested  several 
times  a  day.  Each  time  a  pair  finishes  a  task,  they  must  integrate  and  release  their 
changes  to  the  team.  The  guidelines  are  that  no  one  must  go  longer  than  a  day 
before  they  integrate. 

11.  40-hour  week  -  XP  teams  work  40-hour  weeks.  Teams  will  never  work  more  than  two 
back-to-back  weeks  that  exceed  40  hours  per  week. 

12.  Coding  standards  -  Since  anyone  can  make  changes  to  any  code  at  any  time, 
the  team  must  use  a  coding  standard.  Teams  define  and  evolve  their  own 
coding  standard. 
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SCRUM 


Scrum  is  an  iterative,  incremental  methodology  for 
managing  agile  software  projects. 


The  Product  Owner 
creates  the  backlog, 
a  prioritized  list  of 
desired  user  stories 


The  Team  selects 
user  stories  from  the 
top  of  the  iist, 
planning  enough  to 
fiil  the  2  to  4  week 
sprint 


Product 

BackEog 


Sprint 

Backlog 


The  Team  buiids 
the  stories  in  the 
sprint,  tracking 
progress  daiiy 


Potcniially 

Shippable 

Product 

Incrciifwinl 


At  the  end  of  the 
sprint  the  feature(s) 
deveioped  are 
potentially  shippable 


Refactoring 

Tasks 


The  cycle  is  repeated  untii  the  backiog  is  emptied, 
the  budget  is  spent,  or  a  deadiine  arrives 
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Development  Activities  Within  an  Agile  Sprint^ 


Team  members 

•  select  the  next  user  story  from  the  top  of  the  sprint  queue. 

•  write  the  unit  tests  for  the  user  story,  then  write  and  test  the  code.^ 

•  interact  with  the  product  owner  and  demo  working  code. 

At  the  end  of  the  sprint 

•  a  retrospective  is  held  to  document  lessons  learned 

•  any  refactoring  work  is  added  to  the  next  sprint 

•  unfinished  user  stories  slip  to  the  next  sprint 


1.  Adapted  from  CMU/SEI-2010-TN-002;  Considerations  for  Using  Agiie  in  DoD  Acquisition 

2. Two  team  members  if  pair  programming 
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Measures  and  Progress  in  Agile  Methods 


Working  software  -  the  potentially  releasable  features  created  during 
each  sprint. 

Burn-down  chart  -  tracks  the  work  completed  and  work  remaining. 

•  two  views  -  the  current  sprint  and  the  overall  project 

•  includes  the  hours  of  effort  remaining  and  the  number  of  tasks  remaining  in 
for  the  sprint  or  project. 

Velocity  -  measures  the  number  of  user  stories  completed  in  a  sprint 
and  can  be  used  to  predict  the  completion  date  range. 

Cyclomatic  complexity  -  a  measure  of  the  “goodness”  of  the  software 
that  is  used  to  establish  the  need  for  refactoring. 
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Topics 


Agile  Overview 

Selecting  the  Appropriate  Agile  Methods 
Maintaining  Consistency  and  Agility  using  TSP 


Software  Engineering  Institute 


Carnegie  Mellon 


Timothy  A.  Chick,  July  201 1 

©2011  Carnegie  Meiion  University 
Twitter  #seiwebinar 


16 


Traditional  and  Agile  Perspective  on  Software  Development 


Design  Process 


Goal 


Problem-solving 

Process 


View  of  the 
Environment 


Type  of  Learning 


Key  Characteristics 


Rationality 


Theoretical  and/or 
Philosophical  Roots 


Traditional  View 


Deliberate  and  formal,  linear 
sequence  of  steps,  separate 
formulation  and  implementation, 
rule-driven 

Optimization 

Selection  of  the  best  means  to 
accomplish  a  given  end  through 
well-planned,  formalized 
activities 

Stable,  predictable 

Single-loop/adaptive 

Control  and  direction 
Avoid  conflict 
Formalizes  innovation 
Manager  is  controller 
Design  precedes  Implementation 

Technical/functional 

Logical  positivism,  scientific 
method 


Agile  Perspective 


Emergent,  iterative  and  exploratory,  knowing  and  action 
inseparable,  beyond  formal  rules 


Adaptation,  flexibility,  responsiveness 

Learning  through  experimentation  and  introspection,  constantly 
reframing  the  problem  and  its  solution 


Turbulent,  difficult  to  predict 


Double-loop/generative 

Collaboration  and  communication;  integrates  different  worldviews 
Embraces  conflict  and  dialectics 
Encourages  exploration  and  creativity;  opportunistic 
Manager  is  facilitator 

Design  and  implementation  are  inseparable  and  evolve  iteratively 
Substantial 

Action  learning,  John  Dewey’s  pragmatism,  phenomenology 


Dyba,  Tore;  Torgeir  Dingsoyr,  What  Do  We  Know  about  Agile  Software  Development,  Published  by  the  IEEE  Computer  Society,  0740-7459/09,  2009 
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Symbiotic  Relationship 


Agile  and  traditional  methods  have  a  symbiotic  relationship,  in  which  the 
process  selected  is  based  on: 

•  Size  of  project/application 

•  Application  donnain 

•  Criticality 

•  Innovativeness 

So  how  does  an  organization  identify  the  agile  practices  that  improve  the 
development  process  without  causing  any  harmful  side-effects  to  the 
product,  project,  system,  or  organization? 
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Five  Critical  Factors 


Boehm  and  Turner  identify  five  critical  Figure  6-1.  Home  Ground  Polar  Chart 
factors  to  guide  method  selection 

I  /  +  ■  I  ■  Personnel 

ano/or  tailoring.  (%Level1B)(%Level2and3) 


Seniority  of  personnel 
Dynamism 

Organization’s  Culture 
Project  size 
Criticality 


40  ■■  15 
30  --  20 

20  --  25 


Criticality 

(Loss  due  to  impact  of  defects) 


Dynamism 

(%  Requirements-change/month) 


“...there  will  be  a  higher  premium  on 
having  methods  available  that  combine 
discipline  and  agility  in  situation- 
tailorable  ways.” 


1.  Boehm,  B.;  R.  Turner  (2004). 
Balancing  Agility  and 
Discipline:  A  Guide  for  the 
Perplexed. 


Size 

(Number  of  personnel) 


Culture 

(%  Thriving  on  chaos  vs.  order) 
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Three  Fundamental  Factors 


1 .  Identifying  the  ability  of  the  organization  to  adopt  agile  practices 

2.  Determining  the  suitability  of  agile  practices  in  the  development  of 
a  given  product  or  system 

3.  Determining  the  suitability  of  agile  practices  for  the  organization 
developing  the  product  or  system. 


Adapted  from  Sidky,  Ahmed;  James  Arther,  Determining  the  Appiicabiiity  of  Agile  Practices  to  Mission  and  Life-critical  Systems, 
Proceedings  of  the  31st  IEEE  Software  Engineering  Workshop  (SEW  2007).  pp  3-12 
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Ability  of  the  Organization  to  Adopt  Agile 


1.  Agile  is  like  any  other  Process  Improvement  Initiative 

Successful  adoption  of  agile  practices  requires  the  absorption  of  associated 
costs,  as  well  as  expending  the  required  time  and  effort. 

2.  Method  for  reaching  a  decision  to  proceed  or  not 

a.  Identify  success  factors,  such  as 

-  Level  of  executive  sponsorship 

-  Organizational  desire  to  improve 

-  Availability  of  resources 

b.  Assess  the  extent  to  which  the  success  factors  are  present 

c.  Make  a  Go/No-go  decision  based  on  assessment  results 


Adapted  from  Sidky,  Ahmed;  James  Arther,  Determining  the  Appiicabiiity  of  Agile  Practices  to  Mission  and  Life-critical  Systems, 
Proceedings  of  the  31st  IEEE  Software  Engineering  Workshop  (SEW  2007).  pp  3-12 
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Suitability  of  Agile  Practices 


1 .  Development  and  product  characteristics  play  a  large  role  in 
determining  the  suitability  of  a  particular  agile  methods 

-  For  example,  life-critical  systems  are  usually  characterized  as  being 
large,  complex,  and  having  long  development  periods 

2.  The  desired  product  qualities  also  play  a  role  in  determining 
appropriate  agile  methods. 

-  For  example.  Maintainability  and  Reliability 


An  agile  practice  is  considered  unsuitable  and  must  be  discarded  when 
it  conflicts  with  integral  product/development  characteristics,  or 
precludes  the  attainment  of  desirable  qualities 


Adapted  from  Sidky,  Ahmed;  James  Arther,  Determining  the  Appiicabiiity  of  Agile  Practices  to  Mission  and  Life-critical  Systems, 
Proceedings  of  the  31st  IEEE  Software  Engineering  Workshop  (SEW  2007).  pp  3-12 
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When  is  this  unsuitabie  or  impracticai?  - 1 


On-site  customer  -  the  customer  must  be  available  full-time  to  answer 
questions  as  they  arise,  preferably  face-to-face,  and  preferably  on-site. 

Many  stakeholders  who  are  unable  to  speak  to  one  another’s  requirements 
and  priorities  (need  for  a  traditional  System’s  Engineer  or  Requirements 
Analysis) 

Minimal  documentation  -  The  discouragement  of  writing  requirements 
and  design  because  of  the  cost  associated  with  developing  and 
maintaining  them  and  the  fact  they  do  not  deliver  value  to  the  customer, 
only  working  software  does 

1.  Staffing  flux  results  in  the  tacit  knowledge  of  the  developers  being  lost, 
which  can  result  in  a  considerable  slowdown  in  the  work 

2.  The  lack  of  documentation  demonstrating  the  origins  of  some  technical 
material  can  be  costly  when  faced  with  an  intellectual  property  lawsuit 


Source  of  examples:  Emam,  Khaled  El;  Finding  Success  in  Smaii  Software  Projects,  Cutter  Consortium,  Agile  Project  Management,  Vol.  4,  No.  1 1 . 
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Suitability  of  Agile  for  the  Organization 


When  mismatches  between  the  agile  method  and  the  organization  are 
identified  before  the  adoption  effort,  the  probability  of  failing  during  the 
adoption  effort  or  introducing  undesirable  agile  practices  is  reduced. 

1.  (Polling  Question  1)  Is  Test-First  Programming  (TFP)  a  mismatch 
when  it  is  determined  that  TFP  will  produce  the  desired  quality,  but 
your  organization  already  has  a  dedicated  Independent  Verification 
and  Validation  (IV&V)  team? 

No,  as  TFP  addresses  how  the  developers  do  unit  testing  and  has  no  effect  on  the  dedicated  test  team 

2.  (Polling  Question  2)  Is  Pair  Programming  a  mismatch  when  it  is 
determined  that  the  method  will  meet  required  product  qualities,  but 
that  the  organization  has  major  collaborative  issues? 

Yes,  as  Pair  Programming  works  best  in  a  collaborative  environment 


Adapted  from  Sidky,  Ahmed;  James  Arther,  Determining  the  Appiicabiiity  of  Agile  Practices  to  Mission  and  Life-critical  Systems, 
Proceedings  of  the  31st  IEEE  Software  Engineering  Workshop  (SEW  2007).  pp  3-12 
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Usage  Varies  -  Microsoft  Agile  Study 


An  agile  practices  survey  of  2,800  developers,  testers,  and  managers 
was  conducted  at  Microsoft. 

•  Nearly  500  (17%)  responded  to  the  survey. 

•  Respondents  had  an  average  of  1 0  years  of  experience 

•  Average  time  on  their  current  team  was  2.5  years 

•  Testers  and  developers  represented  73%  of  the  respondents 

•  Managers,  and  managers  of  managers  represented  24%  of  respondents 

•  More  than  60%  of  the  respondents  work  on  legacy  products 


Nagappan,  N;  Begel,  A,  Usage  and  Perceptions  of  Agile  Software  Development  in  an  Industrial  Context:  An  Exploratory  Study,  2007 
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Microsoft  -  Agile  Adoption  by  Practice 


Team  coding  standards 
Continuous  integration  of  code 
System  metaphor 
Simple  design 
Sustainable  pace 
User  stories 
Small  releases 
Direct  interaction  with  customer 
Design  improvement 
Collective  code  ownership 
Acceptance  testing 
Whole  team  daily  stand-up  meeting 
Test-driven  development 
Pair  programming 


0%  10%  20%  30%  40%  50%  60%  70%  80%  90%  100% 


■  Yes  □  Sometimes  □  Planning  to  □  No  ■  Never  will 
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Microsoft  -  Attitude  towards  Agile 


Agile  is  working  well  for  me. 
Agileis  working  well  for  my  team. 

Agileis  working  well  for  my  larger  group. 

My  team's  morale  has  improved  because  we 
adopted  Agile  methods. 

My  team's  developers  and  testers  collaborate  more 
with  Agile  than  before  we  adopted  Agile  methods. 


0%  20%  40%  60%  80%  100% 


■  Strongly  agree  □  Agree  □  Neutral  □  Disagree  ■  Strongly  disagree 
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Topics 


Agile  Overview 

Selecting  the  Appropriate  Agile  Methods 
Maintaining  Consistency  and  Agility  using  TSP 


Software  Engineering  Institute 


Carnegie  Mellon 


Timothy  A.  Chick,  July  201 1 

©2011  Carnegie  Meiion  University 
Twitter  #seiwebinar 


28 


Maintaining  Consistency  and  Scaiability 
with  Agility 

How  does  the  developing  organization  empower  teams  to  make 
these  process  selections,  while  maintaining  consistency  and  agility 
throughout  the  organization? 
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Simple  But  Not  Easy 


"Everything  should  be  made 
as  simple  as  possible,  but  not 
simpler." 


"For  every  complex  problem, 
there  is  a  solution  that  is 
simple,  neat,  and  wrong." 
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Team  Software  Process 


The  Team  Software  Process  (TSP) 
is  a  process  framework  that  was 
specifically  designed  for  software 
teams. 

It’s  purpose  is  to  help  teams  achieve 
their  best  performance  by  showing 
them  how  to 

•  accurately  estimate  and  plan 
their  work 

•  negotiate  their  commitments 
with  management 

•  manage  and  track  projects  to  a 
successful  conclusion 

•  manage  quality  to  produce  better 
products  in  less  time 
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TSP  and  Agile  - 1 

Individuals  and  interactions  over  processes  and  tools 

•  TSP  holds  that  individuals  are  the  key  to  product  quality  and  effective 
member  interactions  are  necessary  for  the  team  to  succeed 

•  Project  launches  strive  to  create  jelled  teams 

•  Weekly  meetings  and  communication  are  essential  to  sustain  them 

•  Teams  define  their  own  processes  in  the  launch 

•  Sharing  leadership  responsibilities  helps  interaction  between  members 

Working  software  over  comprehensive  documentation 

•  TSP  teams  can  choose  evolutionary  or  iterative  lifecycle  models  to  deliver 
early  functionality  -  the  focus  is  on  high  quality  working  software  from  the 
start.  TSP  does  not  require  heavy  documentation 

•  Documentation  should  merely  be  sufficient  to  facilitate  effective  reviews 
and  information  sharing 

•  TSP  teams  can  determine  the  level  of  documentation  produced  based  on 
organizational  standards,  customer  needs,  and  system  attributes. 


Source:  Lussier,  Frederick,  CMMI  Agile  Processes  -  PSP/TSP.  Alcyonix  Inc.,  http://www.slideshare.net/flussier/psp-tsp-aaile-3-0-en 
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TSP  and  Agile  -  2 

Customer  collaboration  over  contract  negotiation 

•  Learning  what  the  customer  wants  is  a  key  focus  of  the  TSP 

•  The  customer  or  a  representative  is  required  to  be  present  when  TSP  teams 
start  planning  the  project  and  first  cycle. 

•  The  customer  or  a  representative  can  also  attend  each  re-launch  to  guide 
plans  for  the  next  cycle. 

•  The  TSP  has  a  team  member  role,  the  Customer  Interface  Manager,  for  the 
purpose  of  collaboration  with  the  customer. 

Responding  to  change  over  following  a  plan 

•  TSP  teams  expect  and  plan  for  change 

•  TSP  teams  re-plan  whenever  the  plan  is  no  longer  a  useful  guide 

•  New  tasks  are  added  as  they  are  discovered 

•  They  dynamically  rebalance  the  team  workload  as  required  to  finish  faster 

•  The  team’s  process  is  adjusted  as  needed  to  improve  performance 

•  The  team  continuously  manages  risk  and  uses  early-warning  indicators  to 
identify  and  avoid  technical  and  planning  issues. 

Source:  Lussier,  Frederick,  CMMI  Agile  Processes  -  PSP/TSP.  Alcyonix  Inc.,  http://www.slideshare.net/flussier/psp-tsp-aaile-3-0-en 
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TSP  is  Agile  and  More 


Features  TSP  and  Agile  Methodologies  Support 

Agile 

TSP 

Team  organization 

Team  organization 

Project  management  -  planning  and  estimating 

Project  management  -  planning  and  estimating 

Change  control 

Change  control 

Requirements 

Requirements 

Design 

Design 

Code  development 

Code  development 

Configuration  control 

Configuration  control 

Testing 

Testing 

Specialization  of  team  members 

Project  management  -  tracking  and  control 

Reusability 


Quality  assurance 
Inspections 
Static  analysis 
Security 

Documentation  and  training 

Software  Engineering  Best  Practices,  C.  Jones,  201 0 


Soflrware 
Engineering 
Best  Practices 
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TSP  is  a  Software  Engineering  Best  Practice 


Small 

4 

Methods 

1)  Agile 

2)  TSP/PSP 

3)  Waterfall 

4)  CMMI  1,  2 


Medium 


Methods 

1)  TSP/PSP 

2)  Agile 

3)  CMMI  3 

4)  RUP 


Large 

4 

Methods 

1)  TSP/PSP 

2)  CMMI  3,  4,  5 

3)  RUP 

4)  Hybrid 


Development  practices  by  size  of  application!^! 


Software  Engineering  Best  Practices,  C.  Jones,  2010 
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Summary 


Agile  is  a  means  to  an  end. 


Decide  upon  your  goals,  how  you  will  measure  success,  then  determine 
what  strategy,  process,  and  activities  help  you  achieve  those  goals. 

TSP  can  provide  the  disciplined,  yet  flexible,  planning,  quality,  and 
process  frameworks  needed  to  successfully  scale  other  Agile  methods 
across  your  organization. 
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Contact  Information 


Timothy  A.  Chick 

Sr.  Member  of  the  Technical  Staff 
TSP  Initiative 

Telephone:  +1  412-268-1473 
Email:  tchick@sei.cmu.edu 

Web 

www.sei.cmu.edu/TSP 

www.sei.cmu.edu/TSPSvmDosium 


U.S.  Mail 

Software  Engineering  Institute 
Customer  Relations 
4500  Fifth  Avenue 
Pittsburgh,  PA  15213-2612 
USA 

Customer  Relations 

Email:  info@sei.cmu.edu 
Telephone:  +1  412-268-5800 

SEI  Phone:  +^  412-268-5800 

SEI  Fax:  -i-l  412-268-6257 
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NO  WARRANTY 


THIS  CARNEGIE  MELLON  UNIVERSITY  AND  SOFTWARE  ENGINEERING  INSTITUTE 
MATERIAL  IS  FURNISHED  ON  AN  “AS-IS"  BASIS.  CARNEGIE  MELLON  UNIVERSITY 
MAKES  NO  WARRANTIES  OF  ANY  KIND,  EITHER  EXPRESSED  OR  IMPLIED,  AS  TO 
ANY  MATTER  INCLUDING,  BUT  NOT  LIMITED  TO,  WARRANTY  OF  FITNESS  FOR 
PURPOSE  OR  MERCHANTABILITY,  EXCLUSIVITY,  OR  RESULTS  OBTAINED  FROM 
USE  OF  THE  MATERIAL.  CARNEGIE  MELLON  UNIVERSITY  DOES  NOT  MAKE  ANY 
WARRANTY  OF  ANY  KIND  WITH  RESPECT  TO  FREEDOM  FROM  PATENT, 
TRADEMARK,  OR  COPYRIGHT  INFRINGEMENT. 

Use  of  any  trademarks  in  this  presentation  is  not  intended  in  any  way  to  infringe  on  the 
rights  of  the  trademark  holder. 

This  Presentation  may  be  reproduced  in  its  entirety,  without  modification,  and  freely 
distributed  in  written  or  electronic  form  without  requesting  formal  permission.  Permission 
is  required  for  any  other  use.  Requests  for  permission  should  be  directed  to  the  Software 
Engineering  Institute  at  permission(a)sei.cmu.edu. 

This  work  was  created  in  the  performance  of  Federal  Government  Contract  Number 
FA8721-05-C-0003  with  Carnegie  Mellon  University  for  the  operation  of  the  Software 
Engineering  Institute,  a  federally  funded  research  and  development  center.  The 
Government  of  the  United  States  has  a  royalty-free  government-purpose  license  to  use, 
duplicate,  or  disclose  the  work,  in  whole  or  in  part  and  in  any  manner,  and  to  have  or 
permit  others  to  do  so,  for  government  purposes  pursuant  to  the  copyright  license  under 
the  clause  at  252.227-7013. 
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